Repository navigation
Conversation
There was a problem hiding this comment.
Copilot was unable to review this pull request because the user who requested the review has insufficient remaining quota. Try requesting a review at a lower effort level.
An organization owner can choose the repository organization as the billing source for reviews requested by members with a paid Copilot license. Learn about Copilot code review billing. Review the Copilot code review billing settings.
![pullfrog[bot]](https://avatars.githubusercontent.com/in/1768019?s=60&v=4){kind=small}
There was a problem hiding this comment.
The feature works for the happy paths: console.log with a template literal, with runtime expressions, and with a constant expression all resolve correctly. The existing tests pass, and I added local checks for vec3f and string expressions, which also work.
Two things I would fix before merging:
-
The
cookQuasisfallback is both unreachable and wrong.cookedis onlynullfor tagged templates with invalid escapes, and the transpiler does not handleTaggedTemplateExpression, so this code path is never reached. If it ever becomes reachable, its replacement order is wrong: it cooks\nbefore\\, so\\nbecomes\+ newline, and the final.replaceAll(/\\/g, '\\')is a no-op. A proper cook needs to be a single left-to-right pass. -
Removing the whole
TemplateLiteralESLint rule is broader than the feature. The generator only supports template literals as direct arguments toconsole.log(and other log ops). Tagged templates (tag\...`) still fail at transpile time withUnsupported JS functionality: TaggedTemplateExpression, and non-log template literals (``const s = \hello`) throw a WGSL type error. Keeping the rule for tagged templates, or narrowing it toconsole.log` arguments, would keep the early lint signal.
I also found two smaller issues: tseynit's stringifyExpression does not escape cooked quasis, so a template literal containing a backtick or ${ produces invalid JS in error messages; and nested template literals are not flattened by generateLog's flatMap, so the log metadata stores a TemplateLiteralExpression object instead of the inner text. The inline comments below cover the details.
Note: 1 inline comment(s) dropped because they did not anchor to lines inside the PR diff:
packages/eslint-plugin/src/rules/noUnsupportedSyntax.ts:63(RIGHT) — line 63 (RIGHT) is not inside a diff hunk
deepseek-v4.1-flash-1017 (free via Pullfrog for OSS) ｜ 𝕏
| return ident[1]; | ||
| } | ||
|
|
||
| function cookQuasis(raw: string): string { |
There was a problem hiding this comment.
This fallback is unreachable for the supported syntax: cooked is only null for tagged templates with invalid escapes, and TaggedTemplateExpression is not handled by the transpiler. If it is ever reached, it is also wrong: \ is cooked before \\\\, so \ becomes \ + newline, and the final .replaceAll(/\\/g, '\\') is a no-op. Consider removing the fallback or implementing a proper single-pass cook.
| return 'TemplateLiteralExpression'; | ||
| } | ||
|
|
||
| [$comptimeValueOf](): ComptimeValue { |
There was a problem hiding this comment.
$comptimeValueOf returns the array of elements, not the template's string value. For a comptime value, the template literal should evaluate to its concatenated string (e.g. a${1}b -> a1b), so asComptime on this object returns a misleading array. This is currently only used in the console.log path, but the wrong comptime value is a latent trap if the expression is reused elsewhere.
| args.flatMap((arg) => | ||
| arg.value instanceof TemplateLiteralExpression ? arg.value.elements : [arg], | ||
| ), |
There was a problem hiding this comment.
This only flattens one level. A nested template literal such as console.log(`outer ${`inner ${4}`} end`) leaves the inner TemplateLiteralExpression in the log args. I verified that logIdToMeta then contains a TemplateLiteralExpression object instead of the inner text, and the runtime would print that object. Consider making the flattening recursive.
| return 'null'; | ||
| } | ||
|
|
||
| if (node[0] === NODE.templateLiteral) { |
There was a problem hiding this comment.
The quasis are already cooked text, so a backtick or ${ in a quasi produces invalid JS in the stringified expression. I verified stringifyNode([108, ['a`b', 'c'], [[5, '4']]]) yields `a`b${4}c`. Use JSON.stringify or re-escape the quasis when building the output.
Closes #1700